• Add automatic database creation in migration script
  - Checks if database exists before running schema
  - Creates database if missing, handles connection errors gracefully
• Reorder provider routes for correct Express routing precedence
  - Move /me/profile and /me/stats routes before /{id} route
  - Prevents parameterized routes from intercepting user-specific endpoints
• Add refresh tokens table to database schema
  - Stores hashed tokens with expiration and revocation status
  - Includes indexes for efficient token lookups
• Fix Dockerfile entry point from server.js to index.js
• Add TypeScript migration script to package.json

Add automatic database creation logic

• Add database existence check and automatic creation before schema migration
• Connect to default postgres database to check if target database exists
• Create database if missing with proper error handling and logging
• Remove commented-out migration tracking code

src/database/migrate.ts

Reorder routes for correct precedence

• Move /me/profile and /me/stats routes before /{id} route
• Ensures user-specific endpoints are matched before parameterized ID routes
• Maintains all Swagger documentation for both endpoints

src/routes/provider.routes.ts

Fix Docker entry point

• Change CMD entry point from dist/server.js to dist/index.js
• Aligns with actual application entry point

Dockerfile

Description

src/database/migrate.ts interpolates config.database.name (DB_NAME) directly into a CREATE DATABASE
statement without identifier escaping/validation, so a name containing a double-quote can break the
SQL and potentially append unintended DDL. This can cause migrations to fail or execute unexpected
statements on the admin connection used for DB creation.

Code

src/database/migrate.ts[R18-37]

+    const dbName = config.database.name || 'hano_db';
+    console.log(`Checking if database "${dbName}" exists...`);
+
+    const client = new Client({
+      host: config.database.host,
+      port: config.database.port,
+      user: config.database.user,
+      password: config.database.password,
+      database: 'postgres', // Connect to default postgres DB first
+    });
+
+    try {
+      await client.connect();
+      const checkDb = await client.query(`SELECT 1 FROM pg_database WHERE datname = $1`, [dbName]);
+
+      if (checkDb.rows.length === 0) {
+        console.log(`Database "${dbName}" not found. Creating it...`);
+        // Cannot use parameterized query for CREATE DATABASE
+        await client.query(`CREATE DATABASE "${dbName}"`);
+        console.log(`✓ Database "${dbName}" created successfully.`);

Evidence

DB_NAME is sourced from the environment with no validation, and is then embedded into CREATE
DATABASE via string interpolation rather than safe identifier-escaping.

src/config/config.ts[78-85]
src/database/migrate.ts[17-37]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`src/database/migrate.ts` constructs `CREATE DATABASE "${dbName}"` using `dbName` from `process.env.DB_NAME` (via `config.database.name`) without validating it as a safe PostgreSQL identifier or escaping embedded quotes. This can break the statement and can enable DDL injection in the migration step.

### Issue Context
PostgreSQL DDL like `CREATE DATABASE` can’t be parameterized like normal value parameters, so the fix should be identifier validation/escaping (not `$1` parameters).

### Fix Focus Areas
- src/database/migrate.ts[17-37]
- src/config/config.ts[78-85]

### What to change
- Add strict validation for `dbName` (e.g., allow only `[A-Za-z_][A-Za-z0-9_]*`), and fail fast with a clear error if invalid.
- Alternatively (or additionally), implement proper identifier escaping (double any embedded `"` to `""`) and still validate length/charset.
- Keep the `SELECT 1 FROM pg_database WHERE datname = $1` check as-is (it’s already parameterized).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

src/database/schema.sql defines refresh_tokens.token_hash as UNIQUE and also creates
idx_refresh_tokens_hash on the same column, resulting in duplicate indexing and unnecessary
write/storage overhead. This adds avoidable cost on refresh token inserts/rotations.

Code

src/database/schema.sql[R249-259]

+CREATE TABLE IF NOT EXISTS refresh_tokens (
+    id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
+    user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
+    token_hash VARCHAR(255) UNIQUE NOT NULL,
+    expires_at TIMESTAMP NOT NULL,
+    revoked BOOLEAN DEFAULT FALSE,
+    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
+);
+
+CREATE INDEX IF NOT EXISTS idx_refresh_tokens_hash ON refresh_tokens(token_hash);
+CREATE INDEX IF NOT EXISTS idx_refresh_tokens_user ON refresh_tokens(user_id);

Evidence

The schema simultaneously declares a UNIQUE constraint on token_hash and then creates a separate
index on token_hash, which is redundant for enforcing uniqueness and lookups on that same column.

src/database/schema.sql[249-259]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`refresh_tokens.token_hash` is declared `UNIQUE`, and the schema also creates `idx_refresh_tokens_hash` on the same column. This duplicates indexing work and increases write overhead.

### Issue Context
A `UNIQUE` constraint already provides an index suitable for lookups by `token_hash`.

### Fix Focus Areas
- src/database/schema.sql[249-259]

### What to change
- Remove `CREATE INDEX IF NOT EXISTS idx_refresh_tokens_hash ON refresh_tokens(token_hash);`
- Keep the UNIQUE constraint on `token_hash` (since the model assumes token hashes are unique).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools